@tyrasd i have describe my thoughts and also the describe the issue in detail , very sorry for ALL-CAPS 🙏🙏

Ok, thanks for that.

The downside of your approach is that this "solution" it is merely addressing the symptom and not the cause of the underlying problem. Admittedly, this was not a trivial one to figure out, but here is what I noticed:

• There are event handlers set for both mouseover and mouseout, which should "in theory" already disable the highlighted state of the previously selected entity when the mouse enters a different element.
• For some reason, the mouseout handler is sometimes not called. There must be some underlying problem causing this event handler not to be triggered properly.
• One of the cases where the event handler is not called is when the DOM element is removed from the page (in items.exit().remove()). This makes sense: when there is no element, there are also no events. So, to fix this case, we need to manually call the mouseout handler when DOM elements are removed. Like this: items.exit().each(d => mouseout(undefined, d)).remove();
• This fixes some cases of the bug, but not all: when the mouse is on the first search result, the highlight can still get stuck. After a bit of debugging, I noticed that items.enter() had always 1 DOM element, even if the search result list had the same length as previously. This should not be the case, as d3 should never have to create new DOM elements when they already exist. So, something must be wrong with the data binding of the search results to the DOM.
• The culprit turned out to be a few lines further above:

            list.selectAll('.feature-list-item')
                .data([-1])
                .remove();

  This was added a long time ago with Adds support for ids and locations as search input #2056.
• This indeed messes up the binding of the first DOM element of the items selection to the first search result, as it is always removed whenever the search results list is updated.
• This explains why the mouseout event is not called for the first element of the search results list, when one types in the search field: As the element is always deleted and immediately recreated in the following items.enter() instruction, the mouse events don't have a chance to be properly triggered.
• I cannot see what useful things the ….data([-1]).remove() instruction would be meant to doing here: it's not related to the functionality of the PR where it was added, and it generally does not seem to make much sense. 🤷 My best guess is that it was accidentally included in the commit and overlooked in the PR review back then.
• Simply removing the culprit 3 lines of code seems to finally fully fix the original issue. Most importantly, this does not require adding any workaround and additional complexity to the code.